home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc757.txt < prev    next >
Text File  |  1994-08-01  |  36KB  |  1,156 lines
  1.  
  2.  
  3. RFC 757
  4.  
  5.  
  6.  
  7.   A Suggested Solution to the Naming, Addressing, and Delivery
  8.                Problem for ARPAnet Message Systems
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.                         Debra P. Deutsch
  22.  
  23.                         10 September 1979
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.                      Bolt Beranek and Newman
  46.  
  47.                         50 Moulton Street
  48.  
  49.                  Cambridge, Massachusetts 02138
  50.  
  51.                          (617) 491-1850
  52. Preface                                                    Page 1
  53.  
  54.  
  55.                              Preface
  56.  
  57.   Unlike   many   RFCs,   this   is  not  a  specification  of  a
  58. soon-to-be-implemented protocol.  Instead this is a true  request
  59. for  comments  on  the concepts and suggestions found within this
  60. document, written  with  the  hope  that  its  content,  and  any
  61. discussion  which it spurs, will contribute towards the design of
  62. the  next  generation  of  computer-based  message  creation  and
  63. delivery systems.
  64.  
  65.   A  number  of  people  have  made contributions to the form and
  66. content of this document.  In particular, I would like  to  thank
  67. Jerry   Burchfiel  for  his  general  and  technical  advice  and
  68. encouragement, Bob Thomas for his  wisdom  about  the  TIP  Login
  69. database  and  design of a netmail database, Ted Myer for playing
  70. devil's  advocate,  and  Charlotte  Mooers  for   her   excellent
  71. editorial assistance.
  72.  
  73.                                                    Debbie Deutsch
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. RFC 757                                            September 1979
  110. Introduction                                               Page 2
  111.  
  112.  
  113. 1. Introduction
  114.  
  115.   The  current  ARPAnet  message handling scheme has evolved from
  116. rather informal, decentralized beginnings.  Early developers took
  117. advantage of pre-existing tools --  TECO,  FTP  --  in  order  to
  118. implement  their  first systems.  Later, protocols were developed
  119. to  codify  the  conventions  already  in  use.     While   these
  120. conventions  have  been  able  to  support an amazing variety and
  121. amount of service, they have a number of shortcomings.
  122.  
  123.   One difficulty is the naming/addressing  problem,  which  deals
  124. with  the  need  both  to  identify the recipient and to indicate
  125. correctly a delivery point for the message.  The current paradigm
  126. is deficient in that it lacks a  sharp  distinction  between  the
  127. recipient's  name  and  the  recipient's  address,  which  is the
  128. delivery point on the net.
  129.  
  130.   The naming/addressing scheme does not allow  users  to  address
  131. their  messages  using  human  names,  but instead forces them to
  132. employ designations better  designed  for  machine  parsing  than
  133. human identification.
  134.  
  135.   Another  source  of  limitations  lies  in the delivery system,
  136. which is simply an extension of the File Transfer Protocol.   The
  137. delivery system is fairly limited in its operation, handling only
  138. simple transactions involving the transfer of a single message to
  139. a  single  user  on  the destination host.  The ability to bundle
  140. messages and the ability to fan-out messages at the foreign  host
  141. would improve the efficiency and usefulness of the system.
  142.  
  143.   An  additional  drawback  to  the delivery system is caused, to
  144. some extent, by the addressing scheme.  A change in  address,  or
  145. incorrect  address  usually  causes the delivery system to handle
  146. the message incorrectly.  While some hosts support  some  variety
  147. of  a  mail  forwarding database (MFDB), this solution is at best
  148. inadequate and spotty  for  providing  reliable  service  to  the
  149. network  as  a  whole.    Because the same username may belong to
  150. different people at different hosts, ambiguities which  may  crop
  151. up  when  messages  are  incorrectly addressed keep even the best
  152. MFDBs from always being able to do their job.
  153.  
  154.   This proposal envisions a system  in  which  the  identity  and
  155. address  of  the  recipient are treated as two separate items.  A
  156. network database supports  a  directory  service  which  supplies
  157. correct  address  information  for all recipients.  Additionally,
  158. the scheme allows mail delivery to be  restricted  to  authorized
  159. users of the network, should that be a desirable feature.
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167. RFC 757                                            September 1979
  168. Names and Addresses                                        Page 3
  169.  
  170.  
  171. 2. Names and Addresses
  172.  
  173.   Today's  ARPAnet  naming and addressing scheme (as specified in
  174. RFC 733[3]) does not discriminate between the identity of a  user
  175.                    1
  176. and   his   address .      Both   are  expressed  the  same  way:
  177. USERNAME@HOST.  While this  should  always  result  in  a  unique
  178. handle for that user, it has proved to be inadequate in practice.
  179. Users  who  change  the  location  of their mailboxes, because of
  180. either a change in affiliation or a simple shift in  host  usage,
  181. also  get their names changed.  If their old host employs an MFDB
  182. the problem is not too bad.  Mail is simply forwarded on  to  the
  183. new  address,  slightly  delayed.  Other less fortunate users who
  184. cannot rely upon an MFDB must notify all their correspondents  of
  185. the  change  in  address/name.    Any  mail  addressed to the old
  186. address becomes undeliverable.  (An excellent discussion  of  the
  187. differences between naming, addressing, and routing is found in a
  188. paper by John Shoch [1].)
  189.  
  190.   The  desire  to  use  "real"  names  in  the  address fields of
  191. messages is also thwarted by the current system.    An  elaborate
  192. system  for  using  human-compatible  vs.   machine-interpretable
  193.                                                         2
  194. information has been evolved for use in message  headers .    The
  195. most  recent  developments  indicate  that  many users would feel
  196. happiest   if    the    real    human    name    could    appear;
  197. machine-interpretable  information should not intrude too heavily
  198. into the writer's work- and thought-space.
  199.  
  200.   The solution proposed here calls for a total break between  the
  201. way  a  recipient is named or identified and the way in which his
  202. location  is  specified.    Since  the  ARPAnet  is  a  regulated
  203. environment,  a  unique  (and  not necessarily human-readable) ID
  204. could be assigned to each authorized recipient of  network  mail.
  205. This  ID  would stay with the user throughout his lifetime on the
  206. network, through changes in address and affiliation.
  207.  
  208.   A network database  (which  could  be  derived  from  the  same
  209. database  that  has  been  proposed  to  support TIP login) would
  210. associate each ID with one or more addresses indicating where the
  211. mail for that ID may be delivered.  If more than one address were
  212.  
  213. _______________
  214.   1
  215.    See, for example, RFC 733's discussion  of  the  semantics  of
  216. address  fields,  in  which  it  is  specified that the To: field
  217. "contains the identity of the primary recipients of the message".
  218.   2
  219.    See the "Syntax of General Addressee  Items"  section  of  RFC
  220. 733.
  221.  
  222.  
  223.  
  224.  
  225. RFC 757                                            September 1979
  226. Names and Addresses                                        Page 4
  227.  
  228.  
  229. associated  with an ID, that would indicate an ordered preference
  230. in delivery points.  The delivery system would  attempt  delivery
  231. to  the first addressee, and, if that failed, try the second, and
  232.      3
  233. so on .  Most IDs would probably have only  one  address.    Also
  234. associated  with each ID would be some information about the ID's
  235. owner:  name, postal address, affiliation, phone number, etc.
  236.  
  237.   Rather than being forced to type some awkward character  string
  238. in  order  to  name  his  correspondent, the writer would have to
  239. supply only enough information to allow some process to determine
  240. the unique identity of the recipient.  This information might  be
  241. the recipient's name or anything else found in the database.
  242.  
  243.   The  access  to  this  data would also free the writer from any
  244. need to know the location of the recipient.  Once the  unique  ID
  245. were  known,  the  correct  location for delivery would be only a
  246. look-up away.
  247.  
  248.  
  249. 2.1 A distributed database approach
  250.  
  251.   It  is  clear  that  if  the  network  database  had  only  one
  252. instantiation  there  would  be  a tremendous contention problem.
  253. All message traffic would be forced to query that  one  database.
  254. This  is  extremely undesirable, both in terms of reliability and
  255. speed.  It is also clear that requiring each host to  maintain  a
  256. complete  local  copy  of  the  entire  network  database  is  an
  257. undesirable and unnecessary burden on the hosts.
  258.  
  259.   A better approach would be to build  some  sophistication  into
  260. the local delivery system, and use local mini-databases which are
  261. based  upon  the contents of a distributed network database.  (It
  262. may be redundant and/or partitioned, etc., but  is  probably  not
  263. resident  on  the  local  host.)    When a local host queries the
  264. network database about an ID (or, in  a  more  costly  operation,
  265. asked  to  supply an ID given enough identification such as name,
  266. etc.)  the database may be asked to return all its information on
  267. that ID.  At this point the local host can enter all or  some  of
  268. that  information  into a locally maintained database of its own.
  269. It will always refer to that database first when  looking  for  a
  270. name  or  address, only calling the network database if it cannot
  271. find  a  local  entry.  Depending  upon  the  desired  level   of
  272. sophistication of the local message handling programs, additional
  273. information  may  be  added  to  that  database,  including,  for
  274.  
  275. _______________
  276.   3
  277.    Multiple  addresses  might  also  be  used  to  indicate  that
  278. multiple deliveries are desired.
  279.  
  280.  
  281.  
  282.  
  283. RFC 757                                            September 1979
  284. Names and Addresses                                        Page 5
  285.  
  286.  
  287. example, nicknames.
  288.  
  289.   The  database  might  be  shared by a cluster of hosts (such as
  290. exist at BBN or ISI), or it might be used by  only  one.    Hosts
  291. which  originate small amounts of message traffic might rely upon
  292. the network database entirely.
  293.  
  294.   The structure and maintenance of the local  databases  is  left
  295. solely  to the local hosts.  They may or may not store addresses.
  296. It may be desirable either to garbage collect  them,  or  to  let
  297. them  grow.  The local databases might be linked to smaller, more
  298. specialized databases which are  owned  by  individual  users  or
  299. groups.    These  individual databases would be the equivalent of
  300. address books in which users  might  note  special  things  about
  301. individuals:    interests,  last  time seen, names of associates,
  302. etc.  The existence and scope of these databases are not mandated
  303. by this scheme, but it does allow for them.
  304.  
  305.   The same individual databases may be used by  message  creation
  306. programs   in   order   to  determine  the  recipient's  ID  from
  307. user-supplied input.  For example, a user may address  a  message
  308. to  someone  named  Nick.    The  message  creation  program  may
  309. associate "Nick" with an ID, and hand that ID off to the delivery
  310. system, totally removing the matter of address or formal ID  from
  311. the user's world.
  312.  
  313.  
  314. 2.2 Delivery
  315.  
  316.   The delivery operation consists of three parts:
  317.  
  318.   1.  Determining  the  address  to which the message must be
  319.       sent,
  320.  
  321.   2.  Sending the message,
  322.  
  323.   3.  Processing by foreign host.
  324.  
  325.   The first step usually means looking up, in either a  local  or
  326. the   network  database,  the  correct  address(es)  for  message
  327. delivery, given the recipient's ID.  Should the ID not  be  known
  328. at  the time the message is submitted for delivery, any operation
  329. necessary to determine that ID (such as  a  call  to  either  the
  330. local  or  network  database)  is  also performed as part of this
  331. step.
  332.  
  333.   The second step is not too different from what  happens  today.
  334. The  local host establishes a connection to the foreign host.  It
  335. is then able to send one or messages to one or more people.   The
  336. options are:
  337.  
  338.    - Bulk mail.  Several recipients all get the same message.
  339.  
  340.  
  341. RFC 757                                            September 1979
  342. Names and Addresses                                        Page 6
  343.  
  344.  
  345.    - Bundled  mail.    Several  messages get sent to the same
  346.      recipient.
  347.  
  348.    - A combination of the above
  349.  
  350.    - One recipient gets one message.
  351.  
  352.   The foreign host should be able to accept mail for each ID.
  353.  
  354.   The rejection of mail for a given ID by the foreign host  would
  355. usually  indicate  an  inconsistency  between  the sender's local
  356. database and the network database.  In this case, the local  host
  357. updates  its  local  database  from  the  network  database,  and
  358. attempts delivery at the "new" host.  (This is mail  forwarding.)
  359. If  a  host  taken  from  the  network  database  is  found to be
  360. incorrect, there is  a  problem  in  the  network  database,  and
  361. appropriate  authorities  are  notified.    Thus, address changes
  362. propagate out from the network database only as  the  out-of-date
  363. information  is  referenced.    This reduces the magnitude of the
  364. local database update problem.
  365.  
  366.   Once the foreign host recognizes the ID(s), the message(s)  may
  367. be   transmitted   to   the   foreign   host.    Upon  successful
  368. transmission, the job of the local host is done.
  369.  
  370.   The third  step  requires  the  foreign  host  to  process  the
  371. message(s).   This is analogous to what may occur in a mail room.
  372. A foreign host may have to sort  the  bundled  or  bulk  mail  it
  373. receives.    In addition, the foreign host might perform internal
  374. or external fan-out functions or other special functions, at  the
  375. option of the ID owner.
  376.  
  377.   The  implemention and design of possible functions which may be
  378. performed in the mail rooms are neither mandated  nor  restricted
  379. by  this  delivery  scheme.  Since they are too numerous to allow
  380. even a small portion of them to be described  here,  only  a  few
  381. examples will be mentioned.
  382.  
  383.   Fan-out  functions  might  include placing messages in multiple
  384. files,  sending  copies  to  one  or   more   other   users,   or
  385. rebroadcasting  the  messages  onto  the  network.  (In that last
  386. case, the foreign host might evaluate an ID  list,  in  much  the
  387. same way that the ITS mail repeater broadcasts messages addressed
  388. to certain mailboxes.)  Special functions might include automatic
  389. hard-copy  creation  or  reply  generation, processing by various
  390. daemons, or any other service found desirable by the host's  user
  391. population  and  administration.    The implementation of fan-out
  392. functions is  up  to  the  local  host,  as  are  any  additional
  393. functions which the user population might wish of its local "mail
  394. room".    Whatever  services  are  available,  the mail room will
  395. distribute the mail to the correct location for each ID.
  396.  
  397.  
  398.  
  399. RFC 757                                            September 1979
  400. Names and Addresses                                        Page 7
  401.  
  402.  
  403. 2.2.1 Additional delivery options
  404.  
  405.   It may be desirable to allow mail rooms to accept a username in
  406. place  of  an ID.  Use of a username is a less reliable method of
  407. addressing than use of an ID.
  408.  
  409.    - A username  may  not  be  sufficiently  unambiguous  for
  410.      getting an ID and host from the network database.
  411.  
  412.    - Since  a  recipient's  username  may change from time to
  413.      time, there is a chance that the  username  supplied  by
  414.                                   4
  415.      the  sender will be incorrect , or that the host may not
  416.      recognize it.
  417.  
  418.      Because a recipient's ID  does  not  change  with  time,
  419.      errors  such  as those caused by username changes cannot
  420.      occur if IDs are used.  Similarities or ambiguities  can
  421.      be discovered before delivery occurs, and the sender can
  422.      be prompted for additional identifying information about
  423.      his intended recipient.
  424.  
  425.    - In  an  even  worse  case,  a correct username can still
  426.      result in an incorrect delivery when it is  paired  with
  427.      an  incorrect  host  or  acted upon by a mail forwarding
  428.              5
  429.      database .
  430.  
  431.      Because unique IDs are unambiguous, the  possibility  of
  432.      such a situation is eliminated by the use of unique IDs.
  433.  
  434.  
  435.  
  436.  
  437. _______________
  438.   4
  439.    A particularly insidious source of addressing errors stems
  440. from  the  inconsistent  use of (human) names and initials to
  441. generate  usernames.  The  sender  can   easily   guess   his
  442. recipient's  username incorrectly by using, or failing to use
  443. a combination of initials and last name.    (For  example,  a
  444. user  wishing  to  address  Jim  Miller at BBNA and using the
  445. address "Miller@BBNA"  will  have  his  message  successfully
  446. delivered to Duncan Miller at the same site.)
  447.   5
  448.    The   author  has  observed  a  mail  forwarding  database
  449. redirect messages  correctly  addressed  to  one  JWalker  to
  450. different JWalker at another host.
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457. RFC 757                                            September 1979
  458. Names and Addresses                                        Page 8
  459.  
  460.  
  461. 2.2.2 Failures
  462.  
  463.   The case in which the network database is found to be incorrect
  464. has  already been discussed.  It may make sense to mark the entry
  465. as "possibly in error" and to notify both  the  network  database
  466.                 6
  467. and the ID owner  when such a situation occurs. In this case mail
  468. delivery  to  the  ID's owner will not occur, but this is not too
  469. bad, considering that that is what happens today when a host does
  470. not recognize a username.
  471.  
  472.   One additional failure mode, the loss of the  network  database
  473. from  the  net,  must  be considered, even though a well-designed
  474. distributed network database should be robust  enough  to  almost
  475. rule out this possibility.
  476.  
  477.   If  such  a failure should occur, the local databases should be
  478. able to handle most of the traffic.  What would be  lost  is  the
  479. ability  to  add  new IDs to the network database, the ability to
  480. change hosts for an ID, the ability to  update  local  databases,
  481. and the ability to query the network database.  In essence, there
  482. would be a regression to the state we are in today.
  483.  
  484.   A  well-administered  network  database  should  be  backed  up
  485. frequently.  Should a catastrophic series  of  hardware  failures
  486. remove  one or more of the network database's hosts from the net,
  487. the database could be moved  elsewhere.    Such  a  change  would
  488. entail  notification  of  all  hosts  on  which  mail originates.
  489. Software which queries the database should be designed to be able
  490. to easily handle such a move.
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505. _______________
  506.   6
  507.    Such notification would presumably  be  by  hardcopy  mail  or
  508. telephone.
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515. RFC 757                                            September 1979
  516. Relationship to TIP Login database                         Page 9
  517.  
  518.  
  519. 3. Relationship to TIP Login database
  520.  
  521.   A  number of references to the TIP Login problem and a database
  522. which has been proposed as part of its solution have been made in
  523. this note.  A series of working papers [5] written by Bob Thomas,
  524. Paul Santos, and Jack Haverty describe an approach to TIP  Login.
  525. In  brief,  the method is to build and maintain a distributed TIP
  526. Login database, containing information necessary to allow  a  new
  527. entity  called a "login-host" to decide whether or not to grant a
  528. user access to a given TIP, and whether or not to allow the  user
  529. to make various modifications to the database itself.
  530.  
  531.   The  TIP  login  database  is derived from a "network user data
  532. base", which contains information above and beyond that necessary
  533. to support TIP login.  This comprehensive database is designed to
  534. support applications other than TIP Login, either directly or  by
  535. means of databases derived from it.
  536.  
  537.   Contained  in  the  TIP  Login  database  are each user's login
  538. string, a list of TIPs the user  is  authorized  to  access,  the
  539. user's  unique  ID, his password, and any other "permissions" (in
  540. addition to which TIPs may be accessed).  These  permissions  may
  541. indicate  that  the user may create, delete, or modify entries in
  542. the database, to assume other user's roles, and to what extent he
  543. may do so.  The notion  of  permissions  as  developed  by  Steve
  544. Warshall is discussed in an NSW memo [2].
  545.  
  546.   It  seems entirely reasonable to derive a netmail database from
  547. the same comprehensive database that is designed to  support  TIP
  548. Login.  The concept of a unique ID is supported by that database.
  549. Much  of  the  required  information  for  a  netmail database is
  550. already included, and the maintenance tools necessary  to  modify
  551. it  seem well-suited for the purpose.  The concept of permissions
  552. extends well to the needs of netmail.   Permissions  specific  to
  553. network  mail  might  include, for example, the ability to modify
  554. the delivery host list associated with a given user.
  555.  
  556.   The  mechanisms  necessary   for   the   maintenance   of   the
  557. comprehensive  network database and its derived databases give us
  558. a netmail database  very  inexpensively.    This  proposal  takes
  559. advantage of that situation.
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573. RFC 757                                            September 1979
  574. Relationship to RFC 753                                   Page 10
  575.  
  576.  
  577. 4. Relationship to RFC 753
  578.  
  579.   RFC  753 [4] describes an internetwork message delivery system.
  580. Very briefly, the approach is to  locate  one  or  more  "message
  581. processing  modules"  (or MPMs) on each network.  These MPMs pass
  582. messages across network  boundaries,  and  are  also  capable  of
  583. making  deliveries  to  users on the local network.  The document
  584. also details a proposed message format, along  the  envelope  and
  585. letter  paradigm.    An external "envelope", read by the delivery
  586. system, allows the (unread) message to be  correctly  routed  and
  587. delivered  to  the  proper  recipient.  Groups of messages passed
  588. between a pair of MPMs are sent together in a "mail bag".
  589.  
  590.   This proposal differs from RFC 753  in  that  it  is  primarily
  591. intended  to  operate  within  a  network  or  a concatenation of
  592. networks using a common host-host protocol, e.g. TCP.  Where  RFC
  593. 753   addresses   the   problems  of  internetwork  communication
  594. (differing  message  formats,  complex   routing,   and   correct
  595. identification  of  the proper recipient), this note concentrates
  596. primarily on what can be done within a single protocol.  The  two
  597. are not incompatible.  While a general internetwork protocol must
  598. provide  general  methods  which can be compatible with different
  599. host-host protocols in different networks,  a  proposal  such  as
  600. this  one  can  capitalize  on  the  capabilities, resources, and
  601. policies of a given  catenet  (catenated  network)  such  as  the
  602. ARPAnet/PRnet/SATNET etc.
  603.  
  604.  
  605. 4.1 Compatibility
  606.  
  607.   The delivery system described in RFC 753 is compatible with the
  608. system  outlined  here.  Let's examine this for each of the three
  609. basic delivery options performed by the MPM.  (In the  discussion
  610. that  follows, "local networks" means a concatenation of networks
  611. using a common host-host protocol, e.g. TCP.   "Foreign  network"
  612. means  some  network  which  uses a different host-host protocol,
  613. e.g. X.25. (See Figure 4-1.)
  614.  
  615.  
  616. 4.1.1 Outgoing message
  617.  
  618.  
  619. 4.1.1.1 RFC 753
  620.  
  621.   The sender's process hands a message to the local network  MPM.
  622. The message may be destined to an address on the local network or
  623. on  a  foreign network.  In the former case, the MPM performs the
  624. local delivery function (see "Incoming message").  In the  latter
  625. case,  the  MPM  passes the message along to another MPM which is
  626. "closer" to the end user.
  627.  
  628.  
  629.  
  630.  
  631. RFC 757                                            September 1979
  632. Relationship to RFC 753                                   Page 11
  633.  
  634.  
  635.  
  636.  
  637.       +---------+  +----------+
  638.       |         |  |          |
  639.       | RCC-NET |  | WIDEBAND |                .......
  640.       |         |  |   NET    |                .     .
  641.       +---------+  |          |                . MPM .
  642.               * *  +----------+                .......
  643. +---------+   * *   *  *   .......                |
  644. |         |   +---------+  .     .           +---------+
  645. | BBN-NET |***|         |__. MPM .  .....    |         |
  646. |         |   | ARPANET |  .......  .   .xxxx| TELENET |
  647. +---------+***|         |***********. G .    |         |
  648.               +---------+***        .....    +---------+
  649.               * *    *  *   **                            .......
  650.        +--------+  +-------+ ***.....    +-------------+  .     .
  651.        |        |  |       |    .   .    |             |--. MPM .
  652.        | SATNET |  | PRNET |    . G .oooo| DIAL-UP NET |  .......
  653.        |        |  |       |    .....    |             |
  654.        +--------+  +-------+             +-------------+
  655.  
  656.  
  657.  
  658.  
  659.    "Local Nets", TCP based        |    "Foreign Nets", other
  660.  (direct addressing using IP)     |     host-host protocols
  661.  
  662.  
  663. *** = TCP   xxx = X.25   ooo = other communications protocol
  664.                         G = gateway
  665.  
  666.  
  667.  
  668.               Figure 4-1: The Internet Environment
  669.  
  670.  
  671.  
  672.  
  673. 4.1.1.2 This proposal
  674.  
  675.   The  sender's  process  determines the proper host for delivery
  676. given the recipient's unique ID.  If the message is  destined  to
  677. the  local  network, delivery takes place as described earlier in
  678. this proposal.  If the recipient is not local, the message may be
  679. passed to an MPM for foreign delivery.  (A discussion of internet
  680. delivery which does not  presuppose  RFC  753  implementation  is
  681. found later in this note.)
  682.  
  683.   The  environment  in which the MPM operates does not assume any
  684. knowledge on the part of the local networks about  addressees  on
  685. foreign networks.  Thus there are two possibilities which arise:
  686.  
  687.  
  688.  
  689. RFC 757                                            September 1979
  690. Relationship to RFC 753                                   Page 12
  691.  
  692.  
  693.    - The recipient has an ID known to the local networks.
  694.  
  695.      In  this  case,  the  local  networks supply the RFC 753
  696.      "address".  This can take place in the  local  networks'
  697.      MPM or the user's sending or mail creation process.
  698.  
  699.    - The recipient is unknown to the local networks.
  700.  
  701.      Here   the  sender  must  supply  "mailbox"  information
  702.      himself, either explicitly or with  help  of  his  local
  703.      host's database.
  704.  
  705.   Thus,  outgoing  mail  as  described in this memo is compatible
  706. with RFC 753, with the benefit of reducing the burden on the  MPM
  707. by handling mail deliveries that are local to local networks.
  708.  
  709.  
  710. 4.1.2 Messages in transit
  711.  
  712.   Traffic between two MPMs is not affected by this proposal.
  713.  
  714.  
  715. 4.1.3 Incoming mail
  716.  
  717.   The MPM on the networks local to the recipient will have access
  718. to  the netmail database, allowing it to translate "mailboxes" to
  719. "addresses".  It can determine the unique ID of the recipient (if
  720. not known), and initiate delivery to that recipient.    Here  RFC
  721. 753 and this proposal complement each other very well.
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747. RFC 757                                            September 1979
  748. Implications of an internetwork message environment       Page 13
  749.  
  750.  
  751. 5. Implications of an internetwork message environment
  752.  
  753.   The  scheme described above is based upon the assumption that a
  754. unique identifier can be assigned to each registered recipient of
  755. mail.  Whether or not this uniqueness  can  be  guaranteed  in  a
  756. fairly  unregulated internetwork environment is questionable.  It
  757. is technically feasible, certainly.  The  difficulties  are  more
  758. political, because it is necessary to gain the cooperation of the
  759. administrators  and  user populations of foreign networks.  Let's
  760. assume cooperation, however, and see  what  might  happen  in  an
  761. internet environment.
  762.  
  763.  
  764. 5.1 Birthplaces
  765.  
  766.   Each  set  of  local  networks would have its own database, for
  767. ease in access.  It does not seem practical to register  each  ID
  768. in every database, however.  That would be unnecessary, and would
  769. create  access  and  storage  problems  at the network databases.
  770. Here the concept of a "birthplace", or ID origin, may be of use.
  771.  
  772.   While an ID does not imply where the user is now,  it  can  say
  773. something  about  who issued it.  A simple system for determining
  774. the address for any ID can be maintained by  having  the  issuing
  775. network  keep  a  pointer  for  each  ID  it  issues.  One double
  776. indirection would yield the desired address, even if the ID  were
  777. not issued on the local nets.  A message originating on the local
  778. nets  with  an ID which is unknown to its database can be handled
  779. by determining the birthplace of the  ID.    An  inquiry  to  the
  780. birthplace  database  would return a list of one or more networks
  781. on which the ID is registered.  An inquiry to any of those  would
  782. get  the requisite information.  All that is necessary to support
  783. this is for the birthplace record (small enough!)   to  be  kept,
  784. and  for  the act of registration at a given net to automatically
  785. cause that net to notify  the  birthplace  of  the  registration.
  786. (Conversely, a de-registration would cause a similar notification
  787. of the birthplace.)
  788.  
  789.  
  790. 5.1.1 ID resolution
  791.  
  792.   The  handling  of ID resolution when the ID is not known to the
  793. local net does not seem to have a solution simpler than  querying
  794. foreign nets until some success is achieved.
  795.  
  796.  
  797. 5.1.2 Hosts in an internet environment
  798.  
  799.   The  substitution  of internet host names for simple host names
  800. should not cause any difficulty.
  801.  
  802.  
  803.  
  804.  
  805. RFC 757                                            September 1979
  806. Implications of an internetwork message environment       Page 14
  807.  
  808.  
  809. 5.1.3 Orphans
  810.  
  811.   Should a birthplace cease to exist (usually because its network
  812. is  dismantled), it would be necessary for a second birthplace to
  813. "adopt" the first birthplace's records.    Notification  of  this
  814. change could be propagated throughout the internet environment in
  815. much  the  same  way as the addition of a new birthplace would be
  816. treated.
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863. RFC 757                                            September 1979
  864. Conclusions                                               Page 15
  865.  
  866.  
  867. 6. Conclusions
  868.  
  869.   While  ARPAnet  message systems have been amazingly successful,
  870. there is much room for improvement in the quality and quantity of
  871. the  services  offered.    Current  protocols  are  limiting  the
  872. development  of  new message systems.  This paper has discussed a
  873. means of providing the underlying support necessary for  building
  874. a   new  generation  of  message  systems  which  can  be  better
  875. human-engineered in  addition  to  providing  more  services  and
  876. greater reliability.
  877.  
  878.   Critics may argue that the proposal is too radical, too much of
  879. a  departure  from  current practice.  After all, today's message
  880. service is extremely straightforward in design, and therefore has
  881. comparatively few failure modes.    The  protocols  in  use  have
  882. descended,  with  relatively  few  changes,  from  the first file
  883. transfer and message format protocols implemented on the ARPAnet.
  884. This makes them well understood; people are aware of  both  their
  885. shortcomings  and  usage.  Finally, there are people who will not
  886. feel comfortable about requiring a network database,  distrusting
  887. the  reliability  and  questioning  the  possible  cost of such a
  888. scheme.
  889.  
  890.   On the other hand, it is undeniably true that very little  more
  891. can  be  done  to  improve  message services while staying within
  892. today's practices.  New message systems which  will  be  able  to
  893. transmit  facsimile,  voice,  and  other  media  along  with text
  894. require us to rethink message formats and do away  with  delivery
  895. protocols  which are predicated upon the characteristics of ASCII
  896. text.  The inception of internetwork message delivery  causes  us
  897. to  re-evaluate  how  we  handle  messages locally.  Finally, the
  898. USERNAME@HOST naming scheme has proved to  be  inadequate,  while
  899. the  divorce of recipients' identities from their locations seems
  900. a promising possibility as a replacement.
  901.  
  902.   The  ARPAnet  will  soon  have  a  distributed   database   for
  903. supporting  TIP  Login.    Only small, incremental costs would be
  904. associated with building and maintaining a  netmail  database  at
  905. the same time.  It can be argued that TIP Login requires at least
  906. the  level  of reliability required by a message delivery system.
  907. If the TIP Login database is successful, a netmail  database  can
  908. work, too.
  909.  
  910.   It  is  clear that we will be implementing a new set of message
  911. format and delivery protocols in the near  future,  in  order  to
  912. allow for multi-media messages, internetwork message traffic, and
  913. the  like.   New message composition and delivery systems will be
  914. built to meet those specifications  and  take  advantage  of  the
  915. avenues  of development which they will open.  If there will ever
  916. be an advantageous time to re-evaluate and re-design how messages
  917. are addressed and delivered, it is now,  when  we  are  about  to
  918. enter  upon  an  entirely  new  cycle  of message composition and
  919.  
  920.  
  921. RFC 757                                            September 1979
  922. Conclusions                                               Page 16
  923.  
  924.  
  925. delivery program implementation.
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979. RFC 757                                            September 1979
  980. References                                                Page 17
  981.  
  982.  
  983.                            REFERENCES
  984.  
  985. [1]   John F. Shoch.
  986.       Inter-Network Naming, Addressing, and Routing.
  987.       In Proceedings, COMPCON.  IEEE Computer Society, Fall, 1979.
  988.  
  989. [2]   Stephen Warshall.
  990.       On Names and Permissions.
  991.       Mass. Computer Associates.  1979.
  992.  
  993. [3]   David H. Crocker, John J. Vittal, Kenneth T. Pogran,
  994.       D. Austin Henderson, Jr.
  995.       STANDARD FOR THE FORMAT OF ARPA NETWORK TEXT MESSAGES.
  996.       RFC 733, The Rand Corporation, Bolt Beranek and Newman Inc,
  997.       Massachussets Institute of Technology, Bolt Beranek and
  998.       Newman Inc., November, 1977.
  999.  
  1000. [4]   Jonathan B. Postel.
  1001.       INTERNET MESSAGE PROTOCOL.
  1002.       RFC 753, Information Sciences Institute, March, 1979.
  1003.  
  1004. [5]   Robert H. Thomas, Paul J. Santos, and John F. Haverty.
  1005.       TIP Login Notes.
  1006.       Bolt Beranek and Newman.  1979.
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038. RFC 757                                            September 1979
  1039. Table of Contents                                          Page i
  1040.  
  1041.  
  1042.                         Table of Contents
  1043.  
  1044. 1. Introduction                                                 2
  1045.  
  1046. 2. Names and Addresses                                          3
  1047.  
  1048. 2.1 A distributed database approach                             4
  1049. 2.2 Delivery                                                    5
  1050.      2.2.1 Additional delivery options                          7
  1051.      2.2.2 Failures                                             8
  1052.  
  1053. 3. Relationship to TIP Login database                           9
  1054.  
  1055. 4. Relationship to RFC 753                                     10
  1056.  
  1057. 4.1 Compatibility                                              10
  1058.      4.1.1 Outgoing message                                    10
  1059.           4.1.1.1 RFC 753                                      10
  1060.           4.1.1.2 This proposal                                11
  1061.      4.1.2 Messages in transit                                 12
  1062.      4.1.3 Incoming mail                                       12
  1063.  
  1064. 5. Implications of an internetwork message environment         13
  1065.  
  1066. 5.1 Birthplaces                                                13
  1067.      5.1.1 ID resolution                                       13
  1068.      5.1.2 Hosts in an internet environment                    13
  1069.      5.1.3 Orphans                                             14
  1070.  
  1071. 6. Conclusions                                                 15
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096. RFC 757                                            September 1979
  1097. List of Figures                                           Page ii
  1098.  
  1099.  
  1100.                       List of Figures
  1101.  
  1102. Figure 4-1:  The Internet Environment                          10
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.  
  1132.  
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154. RFC 757                                            September 1979
  1155.  
  1156.